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Abstract 


In  1997,  Defence  Research  Establishment  Ottawa  and  Communications  Research  Centre 
started  research  into  an  omni-band  reconfigurable  terminal.  Such  a  terminal  will  enable  soldiers  to 
use  a  single  terminal  to  communicate  over  any  satellite  communications  or  terrestrial  link.  Each 
terminal  will  support  multiple  standards  and  the  first  one  to  be  implemented  will  be  extremely  high 
frequency  medium  data  rate  communications.  Development  begins  with  two  hardware  simulators: 
the  payload  simulator  and  the  ground  terminal  simulator.  Each  simulator  has  a  PC-based  host  to 
run  the  simulator,  a  digital  chassis  containing  several  digital  signal  processor  boards  to  run  the 
payload  or  terminal,  and  a  radio  frequency  chassis  to  interface  to  the  digital  boards.  Within  the 
simulators,  specifically  on  the  digital  signal  processor  boards,  it  is  desirable  to  have  a  common 
data  format  for  interchange  between  modules  to  simplify  interfacing  and  reconfiguration. 

This  document  contains  the  data  packet  format,  data  packet  validation,  description  of  the 
minimum  implementation,  expansion  capabilities,  coding  excerpts  and  the  listing  of  necessary 
definitions  for  coding.  The  requirements  of  flexibility,  simplicity  and  future  expandability  drove 
the  design  of  the  data  packets.  Since  the  data  packet  design  precedes  the  detailed  system  design, 
future  expandability  was  a  key  requirement.  The  data  packet  consists  of  a  variable  length  header 
and  a  variable  length  data  area.  The  header  includes  the  details  of  the  data  storage  as  well  as 
information  about  the  data  source  and  destination. 

There  is  sufficient  versatility  in  the  specification  to  allow  the  data  packet  to  be  used  for  all 
known  intermodule  data,  and  for  new  requirements.  It  is  likely  that  this  specification  will  be  further 
refined  as  requirements  become  firmer  and  the  design  of  the  simulator  becomes  better  defined. 


Resume 

En  1997,  le  Centre  de  recherches  pour  la  defense  Ottawa  et  le  Centre  de  recherches  des 
communications  ont  entrepris  une  recherche  sur  une  station  terrestre  reconfigurable  a  omni-bande. 
Cette  station  terrestre  serait  capable  de  communiquer  sur  n’importe  quelle  bande  de  frequence, 
qu’elle  soit  terrestre  ou  par  satellite.  Chaque  station  supportera  une  multitude  de  normes  de 
communication  et  la  premiere  qui  sera  implantee  sera  celle  de  la  bande  millimetrique  a  taux  moyen 
de  donnees.  La  recherche  commence  avec  la  developpement  de  deux  simulateurs  hardware.  Dans 
chaque  simulateur,  il  y  aura  un  ordinateur  PC  pour  le  commander,  plusieurs  cartes  a  traitement 
numeriques  et  un  chassis  frequence  radio  pour  l’interface  des  cartes  numeriques.  Entre  les 
modules,  particulierement  pour  le  traitement  numerique,  il  est  important  d’avoir  un  format  de 
donnees  commun  qui  permet  la  reconfiguration  et  qui  simplifie  Finterface. 

Dans  ce  rapport,  le  format,  la  validation,  la  realisation  minimum,  les  possibilities 
d’accroissement,  les  exemples  de  logiciels  et  les  definitions  necessaires  pour  programme  des 
paquets  de  donnees  sont  foumis.  La  flexibility,  la  simplicity  et  le  potentiel  de  Faccroissement  ont 
influence  la  conception  des  paquets  de  donnees.  La  capacity  de  faire  des  changements  etait 
essentielle  parce  que  la  conception  du  systeme  n’est  pas  encore  finalisee.  L’en-tete  des  paquets  de 
donnees  ainsi  que  la  donnee  elle-meme  est  de  longueur  variable.  L’en-tete  contient  les  details  de 
Fentreposage  des  donnees  et  Finformation  de  la  source  et  de  la  destination. 

Cette  specification  est  assez  versatile  pour  permettre  aux  paquets  de  donnees  d’etre 
utilisees  partout  dans  les  simulateurs.  Il  est  probable  que  cette  specification  deviendra  plus 
raffinee  quand  la  definition  du  systeme  sera  terminee. 
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Executive  Summary 


In  1997,  Defence  Research  Establishment  Ottawa  (DREO)  and  Communications  Research 
Centre  (CRC)  started  research  into  an  omni-band  reconfigurable  terminal.  Such  a  terminal  will 

*  enable  soldiers  to  use  a  single  terminal  to  communicate  over  any  satellite  communications  or 
terrestrial  link.  On  ships,  several  of  these  terminals,  to  provide  redundancy  and  concurrent 
communications  over  different  links,  could  replace  the  current  multiplicity  of  communications 

*  installations.  Each  terminal  will  support  multiple  standards  and  the  first  one  to  be  implemented 
will  be  extremely  high  frequency  (EHF)  medium  data  rate  (MDR)  communications.  This  also 
provide  the  technical  knowledge  necessary  to  support  the  Canadian  Military  Satellite 
Communications  project. 

In  the  MDR  system,  there  are  two  simulators:  the  payload  simulator  and  the  ground 
terminal  simulator.  Each  simulator  has  a  PC-based  host  that  provides  operator  control,  permanent 
storage,  and  development  capability.  There  is  also  a  digital  chassis  containing  several  digital 
signal  processor  boards,  custom  general  purpose  boards,  and  specialized  analog-to-digital  and 
input/output  boards.  Together,  these  provide  the  functionality  for  ground  terminal/payload  control, 
access/resource  control,  synchronization  control  and  communications  processing.  A  radio 
frequency  chassis  includes  hopping  synthesizers,  up  and  down  conversion  chains  with  associated 
amplifiers,  mixers  and  filters. 

Within  the  simulators,  specifically  on  the  DSP  boards,  there  will  be  many  types  of  data 
passed  between  boards,  processors  and  routines.  This  data  has  many  forms,  some  examples  are 
data  bits,  encoded  data  bits,  cryptographic  key  streams,  synchronization  estimates  and  analog-to- 
digital  samples.  It  is  desirable  to  have  a  common  format  that  includes  the  various  types  of  data. 
Having  a  common  format  would  simplify  interfacing  and  make  it  easier  to  reconfigure  for  different 
communications  systems. 

Within  this  document,  the  data  packets  used  between  modules  within  the  simulator  are 
specified.  The  requirements  of  flexibility,  simplicity  and  future  expandability  drove  the  design  of 
the  data  packets.  It  is  important  that  the  data  packets  be  flexible  to  support  different  data  such  as 
bits,  symbols,  or  digitized  analog  samples.  This  data  can  be  packed  for  storage  efficiency  or 
unpacked  for  rapid  manipulation.  The  extraction  and  storing  of  data  within  the  packets  is  simple 
and  does  not  take  excessive  overhead.  The  data  packet  design  uses  the  target  processor 
(TMS  320C6201)  word  size  and  includes  aids  in  the  header  to  simplify  extraction  of  the  data. 

Since  the  data  packet  design  precedes  the  detailed  system  design,  future  expandability  is  a  key 
requirement.  The  design  allows  for  different  data  types,  sizes  and  packing.  It  also  allows  for 
different  usage  of  the  data  packets  that  cannot  be  predicted  at  this  time. 

This  document  describes  the  format  of  the  data  packet  and  provides  a  section  on  the 
validation  that  must  be  performed  by  each  module  prior  to  using  the  data.  Also  provided  is  a 
description  of  the  minimum  implementation  of  data  packet  handling  for  initial  development  of  bit 
handling  and  A/D  sample  handling  modules.  Expansion  capabilities  of  the  data  packet 
»  specification  are  given.  Finally,  coding  excerpts  for  handling  of  these  data  packets  and  the  listing 

of  necessary  definitions  for  coding  are  given. 

The  data  packet  consists  of  a  variable  length  header  and  a  variable  length  data  area.  The 
-  header  includes  the  details  of  the  data  storage  as  well  as  information  about  the  data  source  and 

destination.  The  specification  allows  for  future  expansion  in  the  header  (format  and  size)  and  for 
different  data  formats. 
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There  is  sufficient  versatility  in  the  specification  to  allow  the  data  packet  to  be  used  for  all 
known  intermodule  data,  and  for  new  requirements.  It  is  likely  that  this  specification  will  be  further 
refined  as  requirements  become  firmer  and  the  design  of  the  simulator  becomes  better  defined. 
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List  of  Abbreviations 


A/D 

Analog  to  digital 

C6201 

Texas  Instruments  fixed-point  TMS  320C6201  digital  signal  processor 

C6701 

Texas  Instruments  floating-point  TMS  320C6701  digital  signal  processor 

CRC 

Communications  Research  Centre 

DATAPACK.H 

Header  file  containing  data  packet  definitions  for  ‘C’  programming 

DREO 

Defence  Research  Establishment  Ottawa 

DSP 

Digital  signal  processor 

EHF 

Extremely  high  frequency 

FSK 

Frequency-shift  keying  modulation 

I 

In-phase 

I/O 

Input/output 

MDR 

Medium  Data  Rate  (4.8  kb/s  to  2  Mb/s) 

PCI 

A  high-speed  bus  used  in  modem  personal  computers 

Q 

Quadrature 

RF 

Radio  frequency 

x86 

The  family  of  personal  computer  processors  including  486  and  Pentium 

VME 

A  bus  used  for  plug-in  processors 

Hexadecimal  Notation 

OxFF  represents  FF  in  base  16  and  is  equal  to  255  in  base  10.  This  follows  the  ‘C’  convention. 


Programming  Definition  Notation 

There  are  several  definitions  to  be  used  by  ‘C’  programmers  with  names  similar  to 
OFF_UNIQUE_WORD  or  HDR_NORMAL.  These  are  definitions  supplied  in  DATAPACK.H 
(section  7  contains  the  listing)  and  should  be  used  rather  than  hard-coded  numbers  when 
programming  in  ‘C’. 
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1.  Introduction 


In  1997,  Defence  Research  Establishment  (DREO)  and  Communications  Research  Centre 
(CRC)  started  research  into  an  omni-band  reconfigurable  terminal.  Such  a  terminal  will  enable 
*  soldiers  to  use  a  single  terminal  to  communicate  over  any  SATCOM  or  terrestrial  link.  On  ships, 

several  of  these  terminals,  to  provide  redundancy  and  concurrent  communications  over  different 
links,  could  replace  the  current  multiplicity  of  communications  installations.  Each  terminal  will 
»  support  multiple  standards.  The  first  standard  to  be  implemented  will  be  extremely  high  frequency 

(EHF)  medium  data  rate  (MDR)  communications.  This  also  provide  the  technical  knowledge 
necessary  to  support  the  Canadian  Military  Satellite  Communications  project. 

Fig.  1  shows  the  block  diagram  for  the  MDR  system  simulator.  There  are  two  main 
simulators  within  the  system:  the  payload  simulator  and  the  ground  terminal  simulator.  Each 
simulator  has  a  PC-based  host  that  provides  operator  control,  permanent  storage,  and  development 
capability.  The  host  is  the  only  portion  that  interacts  with  the  user.  In  addition  to  the  host,  there  is 
a  digital  chassis  containing  several  digital  signal  processor  (DSP)  boards,  custom  general  purpose 
boards,  and  specialized  analog-to-digital  (A/D)  and  input/output  (I/O)  boards.  Together,  these 
provide  the  functionality  for  ground  terminal/payload  control,  access/resource  control, 
synchronization  control  and  communications  processing.  A  radio  frequency  (RF)  chassis  includes 
hopping  synthesizers,  up  and  down  conversion  chains  with  associated  amplifiers,  mixers  and 
filters.  The  RF  chassis  is  based  on  a  modular  design  to  allow  substitution  for  different  bands. 

1.1  The  Problem 

Within  the  simulators,  specifically  on  the  DSP  boards,  there  will  be  many  types  of  data 
passed  between  boards,  processors  and  routines.  This  data  has  many  forms.  Some  examples  are 
data  bits,  encoded  data  bits,  cryptographic  key  streams,  synchronization  estimates  and  analog-to- 
digital  samples.  It  is  desirable  to  have  a  common  data  format  that  includes  all  the  various  types  of 
data.  A  common  format  simplifies  interfacing  and  reconfiguration  for  different  communications 
systems. 

This  document  specifies  the  data  packets  used  between  modules  within  the  simulator.  An 
example  of  such  a  packet  is  the  data  packets  used  between  the  coder  and  interleaver  of  the 
communications  processor. 


1.2  Requirements 

The  requirements  of  flexibility,  simplicity  and  future  expandability  drove  the  design  of  the 
data  packets.  It  was  important  that  the  data  packets  be  flexible  to  support  different  data  such  as 
bits,  symbols,  or  digitized  analog  samples.  This  data  can  be  packed  for  storage  efficiency  or 
unpacked  for  rapid  manipulation. 

The  process  of  extraction  and  storage  of  data  within  the  packets  must  be  simple  and  not 
take  excessive  overhead.  Thus  the  data  packet  design  uses  the  target  digital  signal  processor 
(C6201)  word  size.  Aids  were  also  included,  in  the  header,  to  simplify  extraction  of  the  data. 
Since  the  data  packet  design  precedes  the  detailed  system  design,  future  expandability  is  a  key 
requirement.  The  design  allows  for  different  data  types,  sizes  and  packing.  It  also  allows  for 
different  usage  of  the  data  packets  that  cannot  be  predicted  at  this  time. 
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Payload  Simulator 
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Fig.  1.  System  block  diagram. 


1.3  Outline 

This  document  first  describes  the  format  of  the  data  packet,  then  the  validation  procedure 
that  must  be  performed  by  each  module  prior  to  using  the  data  is  given.  This  is  followed  by  a 
description  of  the  minimum  implementation  of  data  packet  handling  for  initial  development  of  bit 
handling  and  A/D  sample  handling  modules.  Expansion  capabilities  of  the  data  packet 
specification  are  given.  Example  coding  excerpts  are  given  for  handling  of  these  data  packets. 
Finally,  the  listing  of  DATAPACK.H  is  given  which  contains  the  necessary  definitions  for  coding. 
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2.  Data  Packet  Format 


2.1  General 

The  data  packet  consists  of  a  variable  length  header  and  a  variable  length  data  area  shown 
in  Fig.  2.  The  header  includes  the  details  of  the  data  storage  as  well  as  information  about  the  data 
source  and  destination.  The  specification  allows  for  future  expansion  in  the  header  (format  and 
size)  and  for  different  data  formats. 


Fig.  2.  Data  packet  diagram. 

The  intent  with  data  packets  is  to  minimize  unnecessary  data  transfer  or  reformatting. 
Modules  will  receive  pointers  to  input  and  output  data  packets  rather  than  being  passed  the  data  on 
the  stack.  Ideally,  the  data  will  only  be  extracted  once,  and  stored  once  during  the  processing. 

2.2  Header 

The  header  is  variable  length,  with  a  minimum  size  of  14  32-bit  words.  The  preferred  size 
to  use  is  16  which  allows  for  two  unused  special  fields  at  the  end  of  the  header.  If  more  special 
fields  are  required,  the  header  length  can  be  increased  to  the  necessary  value.  Fig.  3  shows  the 
header  including  the  distinct  32-bit  fields. 

The  header  consists  of  16  fields  of  32  bits  each.  All  fields  in  the  header  must  be 
completed.  The  different  fields  of  the  header,  along  with  values  to  be  used  and  “.h”  definitions 
used  to  access  them  are  given  the  following  table: 
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Data  Size 


Data  Source 


Data  Destination 


Data  Type 


Word  Size 


Word  Type 


Packing  Density 


Symbol  Size 


Symbol  Mask  (low  word) 


Symbol  Mask  (high  word) 


Output  Format 
Special  0 
Special  1 


Fig.  3.  Data  packet  header  diagram. 


Table  1.  Data  packet  header  fields. 


Offset 

Definition 

Description 

Legal  Values 

0 

OFFJJNIQUE_WORD 

This  is  a  unique  word  used  to 
delimit  and  identify  a  data 
packet. 

HDR_UNIQUE_WORD 

■ 

OFF_HEADER_TYPE 

For  future  expansion,  this 
field  allows  different  kinds  of 
headers 

HDR_NORMAL 

(other  values  may  be  added  later) 

2 

OFF_HEADER_SIZE 

This  indicates  the  header  size 
in  32-bit  words.  Larger  sizes 
allow  more  special  fields. 

Since  the  data  follows 
immediately  after  the  header, 
this  also  is  the  offset  to  the 
data  area. 

Minimum  14,  but  normally  16 

3 

OFFJ3ATA_SIZE 

This  is  the  data  area  size  in 
32-bit  words. 

Minimum  1 

Offset 


Definition 


OFF  WORD  TYPE 


OFF  PACKING  DENSITY 


OFF  SYMBOL  SIZE 


OFF  SYMBOL  MASK  LO 


Description 


This  is  the  module  that  is  the 
source  of  the  data.  It  can  be 
used  to  verify  the  data 
packet’s  origin.  It  can  also  be 
used  by  a  module  to 
distinguish  data  packets  from 
various  sources. 


This  is  the  destination  of  the 
packet.  For  an  input  packet, 
this  should  match  the 
executing  module.  For  an 
output  packet,  typically  the 
module  is  not  known. 


This  is  the  type  of  data 
packet.  Some  modules  may 
receive  different  data  and  this 
allows  them  to  be 
distinguished. 


This  is  the  word  size  used  for 
extracting  the  data  from  the 
data  area.  (It  is  not  used  for 
header/data  sizes  which  are 
always  32  bits.) 


This  is  the  bit  format  of  the 
data.  Integer  values  are 
signed.  Floating  point  values 
have  sign  and  exponent. 


This  is  the  number  of 
symbols  stored  per  word  (32 
or  64  bits  depending  on  word 
size).  Symbols  cannot  cross 
word  boundaries. 


This  is  the  mask  used  to 
extract  bits  from  a  packed 
word.  For  32-bit  word  size, 
only  the  low  part  is  used.  For 
64-bit  word  size,  the  high 
part  (below)  is  also  used. 


Legal  Values 


MOD_ACCESS_GENERATION 

MOD_ACCESS_PROCESSENG 

MOD_CRC_DECODER 

MOD_CRC_ENCODER 

MOD_DATAJNPUT 

MOD^DATA  OUTPUT 

MODJ)ECODER 

MOD_DEINTERLEAVER 

MODJENCODER 

MOD_DEMODULATOR 

MOD  FRAME  EXTRACTOR 

MOD_FRAMEJFORMATTER 

MOD~FREQUENCY  DEPERMUTE 

MOD_FREQUENCY_PERMUTE 

MODJNTERLEAVER 

MODJvlODULATOR 

MOD_RESOURCE_ALLOCATOR 

MOD_RESOURCE_REQUESTER 

MOD_SYNC_PROCESSOR 

MODJTIME_CONTROLLER 

MODJTIMEJDEPERMUTE 

MODjnMEJPERMUTE 

MOD  TRANSEC 


Same  as  above.  Also,  for  output 
packets  the  following  value  is 
normally  used: 

MOD  UNKNOWN 


TYPE  STANDARD 


(others  value  may  be  added  later) 


WORD_32_BITS  (normal) 
WORD_64_BITS  (used  only  for 

double  and  40  bit 
longs) 


WORDJJNSIGNED  (normal  bits) 
WORDJNTEGER  (normal 
samples) 

WORD  FLOAT  (floatingpoint) 


1  (unpacked) 

2  or  more  (packed) 

The  maximum  packed  value  is: 
Word  Size  /  Symbol  Size 


See  Table  2 


5 


Offset 

Definition 

Description 

Legal  Values 

12 

OFF_SYMBOL_MASK_HI 

This  is  the  high  part  of  the 
mask  used  to  extract  bits 
from  a  packed  word.  This 
part  is  only  used  for  64 -bit 
word  size  and  then  is  used 
with  the  low  part  of  the  mask 
(above). 

See  Table  2 

13 

OFF_OUTPUT_FORMAT 

This  is  the  output  fonnat 
requested  by  the  process 
invoking  the  module  for  most 
efficient  processing  of  the 
subsequent  module.  It  should 
be  adhered  to  where  possible, 
but  is  not  compulsory. 

OUT_UNSPECEFIED  (no 

preference) 

OUT  ^UNPACKED  ( 1  symbol  / 

word) 

OUT_PACKED  (maximum 

symbols  / 
word) 

(other  values  may  be  added  later) 

14 

OFF_SPECIAL_0 

This  is  a  special  field  as  yet 
unassigned  to  allow  for  future 
expansion  and  custom  uses 
between  modules. 

SPEC  JJNUSED  (not  used  now) 

15 

OFF_SPECIAL_l 

This  is  a  special  field  as  yet 
unassigned  to  allow  for  future 
expansion  and  custom  uses 
between  modules. 

SPEC  JJNUSED  (not  used  now) 

The  next  table  presents  the  various  types  of  data  symbols  to  be  used  in  the  data  packets 
along  with  their  associated  sizes  and  the  masks  used  to  extract  them  from  the  data  area. 

Table  2.  Data  packet  header  symbol  size  and  mask  detail. 


Symbol  Size 
(bits) 

Symbol  Mask 
(Low  word) 

Symbol  Mask 
(High  word) 

Use 

1 

0x1 

0x0 

normal  bits 

3 

0x7 

0x0 

FSK  symbol 

3  or  4 

0x7  or  OxF 

0x0 

soft  decision  bits 

8 

OxFF 

0x0 

byte 

16 

OxFFFF 

0x0 

A/D  samples 

32 

OxFFFFFFFF 

0x0 

integer 

32 

OxFFFFFFFF 

0x0 

float 

40 

OxFFFFFFFF 

OxFF 

long  integer 

64 

OxFFFFFFFF 

OxFFFFFFFF 

double 

2.3  Data  Area 

The  data  area,  which  follows  immediately  after  the  header,  consists  of  a  sequence  of 
symbols.  If  in  unpacked  format,  there  is  one  symbol  per  word.  If  packed,  the  maximum  number  of 
symbols  that  fit  evenly  in  a  word  will  be  used.  Packed  symbols  do  not  cross  word  boundaries. 

This  can  result  in  some  wasted  bits.  Any  unused  bits  must  be  set  to  0.  (Sign  extension  is  not 
allowed.) 
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Long  or  double  values  are  to  be  stored  least  significant  word  first  (lowest  address) 
followed  by  most  significant  word.  A/D  samples  will  be  stored  with  the  in-phase  (I)  sample  first 
followed  by  the  quadrature  (Q)  sample. 

The  size  of  the  data  area  is  application/module  dependent  but  the  design  goal  is  to  ensure  a 
data  packet  contains  one  frame’s  worth  of  data.  The  module  should  not  restrict  the  data  size  and 
should  be  able  to  handle  data  packets  of  just  one  symbol.  Varying  size  of  data  packets  and  module 
algorithms  mean  that  there  will  not  be  a  one-to-one  correspondence  between  input  packets  and 
output  packets.  All  modules  will  return  a  logical  TRUE  if  the  output  packet  contains  valid  data. 
(This  will  not  be  part  of  the  packet  itself.) 


3.  Essential  Validation 

To  ensure  robustness,  it  is  essential  that  all  modules  validate  the  data  packet  header  prior 
to  processing  the  data.  Validation  is  to  ensure  that  it  is  a  data  packet,  that  it  was  meant  to  be 
processed  by  this  module,  and  finally  that  it  is  in  a  format  that  can  be  handled  by  this  module.  The 
fields  that  must  be  validated  are: 

a.  Unique  Word:  must  be  HDR  UNIQUE  WORD 

b.  Header  Type:  must  be  a  supported  type 

c.  Header  Size:  must  be  at  least  14 

d.  Data  Destination:  must  match  current  module 

e.  Data  Type:  must  be  a  supported  type 

f.  Word  Size:  must  be  a  supported  size 

g.  Word  Type:  must  be  a  supported  type 

h.  Packing  Density:  must  be  a  supported  density 

i.  Symbol  Size:  must  be  a  supported  size 

j.  Output  Format:  must  be  a  supported  format 

Validation  must  proceed  in  the  order  of  the  fields.  This  is  especially  important  if  different 
headers  types  are  used  later  where  some  of  the  fields  may  be  redefined.  If  any  validation  fails,  it  is 
important  that  processing  not  continue  and  that  an  error  message  be  generated. 

The  header  does  not  include  any  special  error  checking  fields  such  as  a  checksum.  This  is 
because  the  overhead  involved  in  computing  end  error  check  was  too  large  compared  to  the 
minimal  risk  of  an  erroneous  transfer  of  data  packet.  Packets  will  be  transferred  within  the  same 
DSP  board  or  through  a  short  shielded  link,  and  it  is  unlikely  that  errors  will  be  caused. 


> 


4.  Minimum  Implementation  for  Initial  Development 


4.1  General 


For  initial  development,  it  is  not  necessary  that  all  modules  support  all  possible 
combinations  of  data  storage.  For  purposes  of  commonality  and  interoperability,  there  are  two 
minimum  implementations  of  data  packet  processing.  The  minimum  implementation  to  be  used 
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depends  on  the  type  of  data:  bits  or  A/D  samples.  Modules  must  always  return  errors  in  the  event 
that  they  cannot  handle  the  data  packet  received. 

4.2  Bit  Data  Packets 

Almost  all  modules  in  the  data  communications  processor  deal  with  bits.  The  minimum 
implementation  for  these  modules  (such  as  interleavers  and  coders)  is: 

a.  Header  Type:  HDRNORMAL 

b.  Header  Size  (32-bit  words):  16  (this  allows  two  unused  special  fields) 

c.  Data  Type:  TYPE_STANDARD 

d.  Word  Size:  WORD_32_BITS 

e.  Word  Type:  WORDJJNSIGNED 

f.  Packing  Density  (symbols/word):  1  (unpacked) 

g.  Symbol  Size  (bits):  1 

h.  Symbol  Mask:  Oxl 

i.  Output  Format:  OUT_UNPACKED 

4.3  A/D  Sample  Data  Packets 

Within  the  data  communications  processor,  at  least  two  modules  deal  with  digitized 
samples:  the  modulator  and  demodulator.  To  handle  A/D  samples,  modules  must  also  support  an 
additional  implementation: 

a.  Header  Type:  HDR  NORMAL 

b.  Header  Size  (32-bit  words):  16  (this  allows  two  unused  special  fields) 

c.  Data  Type:  TYPE  STANDARD 

d.  Word  Size:  WORD_32_BITS 

e.  Word  Type:  WORDJNTEGER 

f.  Packing  Density  (symbols/word):  1  (unpacked) 

g.  Symbol  Size  (bits):  16 

h.  Symbol  Mask:  OxFFFF 

i.  Output  Format:  OUT_UNPACKED 

5.  Expansion  of  the  Data  Packet  Specification 

5.1  General 

It  is  anticipated  that  the  definition  provided  here  will  need  to  be  expanded  as  the 
development  of  the  simulator  progresses  and  requirements  become  better  defined.  The 
specification  deliberately  includes  room  for  expansion  in  various  areas  described  below  in  order 
from  least  to  most  effect  on  the  specification. 

5.2  Special  Fields 
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Every  data  packet  will  normally  have  at  least  two  special  fields  at  the  end  (to  round  the 
header  size  to  16  words).  At  this  time,  there  is  no  special  use  for  the  fields.  Later,  they  could  be 
used  to  identify  an  access,  user,  service  or  terminal  for  the  access  control  routines.  They  could 
also  be  used  to  include  time  (absolute  or  by  hop  number,  and  frame  number)  for  synchronization 
routines.  If  the  data  has  some  form  (such  as  rectangular)  then  the  special  fields  could  be  used  for 
row  and  column  size. 

5.3  Use  of  Symbols  for  Legal  Values 

All  options  provided  for  the  legal  values  are  identified  by  symbols  defined  in 
DATAPACK.H.  It  is  relatively  easy  to  add  additional  options  by  adding  more  definitions.  For 
example,  if  more  detail  if  needed  for  the  output  format  field,  it  would  be  easy  to  add  a  symbol  for  a 
specific  type  of  packed  data  output  (say  16  bits  per  word). 

5.4  Inclusion  of  Support  for  Floating  Point 

Though  the  target  digital  signal  processor,  C6201,  does  not  support  floating  point,  the 
6701  will  have  that  capability.  It  may  be  advantageous  to  use  floating  point  representation 
especially  for  packets  used  by  the  synchronization  processor.  The  definitions  provided  in 
DATAPACK.H  contains  symbols  to  support  single  and  double  precision  floating  point  data. 

5.5  Data  Type  Field 

Some  modules,  such  as  the  synchronization  processor,  will  generate  or  accept  different 
types  of  data,  possibly  to  or  from  the  same  module.  By  specifying  a  different  data  type,  type  data 
packets  can  be  easily  distinguished. 

5.6  Header  Size  Field 

The  header  size,  recommended  to  be  16,  allows  for  two  special  fields.  By  increasing  the 
header  size,  extra  fields  which  are  needed  for  special  data  packets  can  be  accommodated.  See  the 
previous  section  on  special  fields  for  their  use. 

5.7  Header  Type  Field 

If  the  data  packet  specification  is  too  restrictive  for  some  unanticipated  requirement,  then  a 
separate  header  type  can  be  defined.  This  allows  changing  the  definition  of  all  subsequent  fields. 

A  different  header  type  will  only  be  used  as  a  last  resort. 


6.  Example  Code  Excerpts 

6.1  General 

Below  are  examples  of  code  to  demonstrate  how  to  invoke  a  module,  how  to  do  the 
validation,  and  how  to  extract  unpacked  and  packed  data.  This  code  has  not  been  tested.  The 
definitions  can  be  found  in  DATAPACK.H  which  is  also  listed  at  the  end  of  this  document. 
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6.2  Invoking  Process 


This  portion  of  the  code  is  in  the  invoking  process  (for  example  the  one  that  calls  the 
interleaver).  The  code  used  here  reflects  the  use  of  an  interleaver  module  and  the  data  packet  has  a 
header  length  of  16  with  32-bit  data  words.  Note  to  minimize  data  transfer,  the  invoking  routine 
passes  a  pointer  to  the  data  packet  rather  than  the  packet  itself.  The  routine  return  data  in  the 
output  packet  withou  modifying  the  input  packet.  Also  note  that  the  interleave  state  is  passed  to 
the  module  as  well  -  this  allows  multiple  uses  of  the  interleaver  without  reinitializing  for  each  use. 


unsigned  int  data_packet_in [ 48 ] ; 
unsigned  int  data_packet_out [48 ] ; 
struct  Interleaver_State  data_interleaver 

. . *  initialize  data_interleaver  for  startup 
. . .  set  values  in  header  and  data  area  of  data_packet_in 

if  (interleave  (data_packet_in,  data_packet_out ,  &data_interleaver )  )  { 

. . .  process  data_packet_out 

}  _ 


6.3  Module  Initial  Code 

Upon  receipt  of  a  data  packet,  the  interleaver  module  validates  the  data  packet  and  sends 
an  error  message  if  the  format  is  not  right  or  not  supported  (this  is  shown  by  the  pseudo-code 
“...crash”).  While  validating  the  header,  the  module  also  does  some  preliminary  work  to  prepare 
for  data  extraction. 


int  interleave (unsigned  int  *dp_in, unsigned  int  *dp_out, 
struct  InterleaverjState  *my  interleaver) 

{ 

unsigned  int  header__size; 
unsigned  int  packing_density 
unsigned  int  *data_base; 
unsigned  int  symbol_size 
unsigned  int  symbol_mask; 
unsigned  int  data_word_N; 
unsigned  int  word_N; 
unsigned  int  shift__N; 

if  (dp_in[OFFJJNIQUE__WORD]  !=  HDR_UNIQUE_WORD)  ...crash 
if  (dp_in[OFF_HEADERJTYPE]  ! =  HDR_NORMAL )  ...crash 
header_size  =  dp_in [OFF_HEADER_SIZE] ; 
if  (header_size  <  14)  .  „ . crash 

if  (dp_in [OFF_DATA_DESTINATION]  !=  MO D_ I NT E RL E AVE R )  ...crash 

if  (dp_in[OFF_DATA_TYPE]  !=  TYPE_STANDARD)  ...crash 

if  (dp_in[OFF_WORD_SIZE]  !=  WORD_32_BITS)  ...crash 

if  (dp_in[OFF_WORD_TYPE]  !=  WORDJJNSIGNED)  .  .  .  crash 

packingjdensity  -  dp_in[OFF__PACKING_DENSITY]  ; 

if  (packing_density  !=  1)  ...crash 

symbol_size  =  dp_in [OFF_SYMBOL_SIZE] ; 

if  (symbol^size  !=  1)  ...crash 

symbol_mask  =  dp_in[OFF_SYMBOL_MASK_LO]  ; 

data_base  =  dp_in  +  header^size; 

if  ( (dp_in[OFF_OUTPUT_FORMAT]  !=  OUT_UN PACKED)  |j 

( dp_in[OFF_OUTPUT_FORMAT]  !=  OUTRUNS PEC I FI ED) )  ...crash 


//  Size  of  header  (words) 

//  Number  of  symbols  per  word 

//  Pointer  to  start  of  data 

//  Number  of  bits  /  symbol 

//  Symbol  bit  mask 

//  Nfh  symbol  value 

//  Word  number  of  desired  symbol 

//  Symbol  location  within  a  word 
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6.4  Module  Extracting  Unpacked  Data 

Within  the  interleaver  module,  when  the  N*  symbol  is  required,  the  following  code  can  be 
used  as  long  as  the  data  is  unpacked  (packing  density  =  1). 


data_word_N  =  data_base [N] ; 


6.5  Module  Extracting  Arbitrarily  Packed  Data 


Within  the  interleaver  module,  when  the  N*  symbol  is  required,  the  following  code  works 
regardless  of  whether  the  data  is  packed  or  not.  This  code  is  less  efficient  than  the  previous  code 
for  unpacked  data.  Simple  optimizations  to  this  code  are  available  if  the  access  to  the  data  is 
sequential. 


word_N  =  N  /  packing_density; 

shift_N  =  (N  %  packing_density)  *  symbol_size; 
data_word_N  =  (data_base [word_N]  »  shift_N)  &  symbol_jnask; 


7.  DATAPACK.H  Listing 

Below  is  the  listing  for  the  header  file  containing  the  symbols  used  in  ‘C’  programs. 


/*=============================_===========:===m=:i;:;=;=:=;===:===:=:=:====:==============*/ 

/*  */ 

/*  DATAPACK.H  */ 

/*  */ 

/*  Header  file  with  definitions  necessary  for  the  header  of  intermodule  */ 

/*  data  packets  within  the  DSP  portion  of  the  simulator.  This  header  file  */ 

/*  should  be  included  in  all  modules.  */ 

/*  */ 

/*  Author:  Robin  Addison  */ 

/*  Language:  TI  C  for  6201,  no  special  compile  flag  requirements  */ 

/*  Hierarchy:  "Include"  with  all  modules  that  pass  data  at  compile  time  */ 

/*  Purpose:  Provide  definitions  to  access  elements  of  the  data  packet  */ 

/*  Inputs:  NA  */ 

/*  Outputs:  NA  */ 

/*  Returns:  NA  */ 

/*  */ 

/*  Change  History:  */ 

/*  */ 

/*  Date  Version  Programmer  Comment  */ 

/* -  -  -  - */ 

/*  11  Jun  98  1.0  Robin  Addison  First  written  */ 

/*  */ 

/*  V 

/*  */ 

/* - V 

/*  Version  number  */ 

#def  ine  VER_DATAPACK_H  1 . 0 

/*  Header  offsets  and  definitions  */ 

^define  OFFJJNIQUE_WORD  0 

_  ^define  HDR_UNIQUE_WORD  0xF981006F 


li 


#def ine 

OFF  HEADER  TYPE 

1 

#define 

HDR  ILLEGAL 

0 

^define 

HDR  NORMAL 

1 

#def ine 

OFF  HEADER  SIZE 

2 

#def ine 

OFF  DATA 

SIZE 

3 

#def ine 

OFF  DATA 

SOURCE 

4 

#def ine 

MOD  ILLEGAL 

0 

#def ine 

MOD  UNKNOWN 

1 

#def ine 

MOD  DATA  INPUT 

2 

^define 

MOD  DATA  OUTPUT 

3 

#def ine 

MOD  ENCODER 

4 

^define 

MOD  DECODER 

5 

#def ine 

MOD  INTERLEAVER 

6 

#def ine 

MOD  DEINTERLEAVER 

7 

#def ine 

MOD  FRAME  FORMATTER 

8 

#def ine 

MOD  FRAME  EXTRACTOR 

9 

^define 

MOD  TIME  PERMUTE 

10 

#def ine 

MOD  TIME  DEPERMUTE 

11 

#def ine 

MOD  FREQUENCY  PERMUTE 

12 

#def ine 

MOD  FREQUENCY  DEPERMUTE 

13 

#def ine 

MOD  MODULATOR 

14 

#def ine 

MOD  DEMODULATOR 

15 

#def ine 

MOD  TRANSEC 

16 

#def ine 

MOD  SYNC  PROCESSOR 

17 

^define 

MOD  TIME  CONTROLLER 

18 

#def ine 

MOD  CRC  ENCODER 

19 

#def ine 

MOD  CRC  DECODER 

20 

#def ine 

MOD  ACCESS  PROCESSING 

21 

#def ine 

MOD  ACCESS  GENERATION 

22 

^define 

MOD  RESOURCE  ALLOCATOR 

23 

#def ine 

MOD  RESOURCE  REQUESTER 

24 

#def ine 

OFF  DATA 

DESTINATION 

5 

/*  use  definitions  from  OFF  DATA 

SOURCE  */ 

#def  ine 

OFF  DATA 

TYPE 

6 

#def ine 

TYPE  ILLEGAL 

0 

#def ine 

TYPE  STANDARD 

1 

#def ine 

OFF  WORD 

SIZE 

7 

^define 

WORD  ILLEGAL 

0 

#def ine 

WORD  32  BITS 

1 

#def ine 

WORD  64  BITS 

2 

^define 

OFF  WORD 

TYPE 

8 

/*  use  WORD  ILLEGAL  from  OFF  WORD 

SIZE  V 

#def ine 

WORD  UNSIGNED 

1 

#def ine 

WORD  INTEGER 

2 

#def ine 

WORD  FLOAT 

3 

#def ine 

OFF  PACKING  DENSITY 

9 

^define 

PACK  ILLEGAL 

0 

#def ine 

OFF  SYMBOL  SIZE 

10 

#def ine 

SIZE  ILLEGAL 

0 

#def ine 

OFF  SYMBOL  MASK  LO 

11 

#def ine 

OFF  SYMBOL  MASK  HI 

12 

#def ine 

OFF  OUTPUT  FORMAT 

13 

#def ine 

OUT  ILLEGAL 

0 

#def ine 

OUT  UNSPECIFIED 

1 

#def ine 

OUT  UNPACKED 

1000 

#def ine 

OUT  PACKED 

2000 

#def ine 

OFF  SPECIAL  0 

14 

#def ine 

SPEC  UNUSED 

0 

#def ine 

OFF  SPECIAL  1 

15 

/*  as  above  */ 
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8.  Conclusion 


The  specification  for  a  variable  length  data  packet  (including  variable  length  header  and 
data  areas)  was  presented.  There  is  sufficient  versatility  in  the  specification  to  allow  the  data 
packet  to  be  used  for  all  known  intermodule  data,  and  for  new  requirements  . 

All  packets  must  have  their  header  validated  before  use  and  the  essential  validations  were 
described.  A  minimum  implementation  necessary  for  all  modules  was  provided  for  initial 
development.  The  expansion  capabilities  of  the  specification  were  presented.  Finally,  coding 
examples  including  symbol  definition  file  listing  were  shown. 

It  is  likely  that  this  specification  will  be  further  refined  as  requirements  become  firmer  and 
the  design  of  the  simulator  becomes  better  defined. 
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chassis  containing  several  digital  signal  processor  boards  to  run  the  payload  or  terminal,  and  a  radio  frequency  chassis  to 
interface  to  the  digital  boards.  Within  the  simulators,  specifically  on  the  digital  signal  processor  boards,  it  is  desirable  to 
have  a  common  data  format  for  interchange  between  modules  to  simplify  interfacing  and  reconfiguration. 

This  document  contains  the  data  packet  format,  data  packet  validation,  description  of  the  minimum  implementation,  expansion 
capabilities,  coding  excerpts  and,  the  listing  of  necessary  definitions  for  coding.  The  requirements  of  flexibility,  simplicity 
and  future  expandability  drove  the  design  of  the  data  packets.  Since  the  data  packet  design  precedes  the  detailed  system 
design,  future  expandability  was  a  key  requirement.  The  data  packet  consists  of  a  variable  length  header  and  a  variable 
length  data  area.  The  header  includes  the  details  of  the  data  storage  as  well  as  information  about  the  data  source  and 
destination. 

There  is  sufficient  versatility  in  the  specification  to  allow  the  data  packet  to  be  used  for  all  known  intermodule  data, 
and  for  new  requirements.  It  is  likely  that  this  specification  will  be  further  refined  as  requirements  become  firmer  and  the 
design  of  the  simulator  becomes  better  defined. 
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